Simulating the behavior of digital systems can often produce ambiguous results. That is, for the same input, the digital system can exhibit several behaviors, all of which are equally valid and in accordance with the specifications. The behavior chosen by the system is a mere idiosyncrasy of the implementation.
One solution for dealing with ambiguous simulation results is the development of a very precise model of the digital system and tight checks on the expected results. The disadvantage of developing a very precise model arises when the system complexity escalates, or the system design evolves from its original definition. Maintaining such a precise model in the face of increased design complexity and a multitude of design changes results in a considerable development and maintenance effort.
Another solution for dealing with ambiguous simulation results is the development of a less stringent model of the digital system, and a looser set of rules to check the results. The disadvantage of developing a less stringent model is that with time, the model diverges from the actual system, and the rules to check the results become increasingly looser, until the model/rules become over-permissive and allow potential defects to slip through. This is especially true for complex concurrent systems with multiple simultaneous activities underway in different states of progress, such as a pipelined digital computer system.
In yet another solution, portholes are introduced into the model of the digital system in order to examine critical states that dictate the eventual outputs produced by the system. The disadvantage of this solution is that it only works in a simulation environment where the state is accessible. However, a digital system can not normally tolerate such an invasive internal examination. Moreover, for increasingly complex systems, the porthole method can be carried to an extreme that leaves the effort to check the design very tightly wed to the system being tested. Thus, the checker loses its independence in providing a valid check of the design in question.
In view of the above, there is a need for a functional testing system which allows the flexibility of building a relatively loose hardware emulator of a digital system, yet provides tighter checking through a set of pre-defined behavioral rules applied to the outputs of the hardware emulator of the digital system.